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FOREWORD 


This final report covers the work performed by 
the Autonetics Division of Rockwell International 
Corporation under Task 2A of Contract NAS9- 12876 
entitled "LSI Fabrication of the Vote r- Comparator - 
Switch, 1st Phase.” Task 2A was amended into the 
Contract NAS9-12876 by modification Mo. IS dated 
October 31, 1972. Task 2A is to define the inter- 
face between a Display and Keyboard Subsystem and a 
Triple Redundant Computer System. 
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1.0 INTRODUCTION 


1.1 OBJECTIVE 

The objective of this study was to define a means of interfacing the 
redundant Display and Keyboard Subsystem with the Triple Redundant Computer 
System (TRCS) as defined in NASA/Ant one' tics Contract NAS9- 12893. The Display 
and Keyboard Subsystem and interface concept were to pattern after Space 
Shuttle design. The Autonetics Space Shuttle control and display studies 
accomplished under Contract NAS9-12266 for NASA MSC and currently being 
accomplished in support of Rockwell International, Space Division, are 
reflected in the interfacing approach described in this report. 

1.2 WORK ACCOMPLISHED 

Hie study was performed in three phases : (1) TRCS conf i gura t x on ana 

characteristics identification, (2) Display and Keyboard Subsystem configura- 
tion and characteristics identification, and (3) Interface approach definition. 

1.3 REPORT CONTENT 

Section 2.0 describes the TRCS. Section 3.0 covers the Display and 
Keyboard Subsystem. Section 4.0 describes the interface approach. 
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2.0 TRIPLE REDUNDANT COMPUTER SYSTEM 

2.1 BACKGROUND) 

Autonetics has developed a Triple Redundant Computer System (TRCS) in 
support to the NASA Space Shuttle activities under Contract NAS9-12893. The 
fundamental purpose of the TRCS system is as a tool to investigate and evalu- 
ate methods of attaining a triple redundant, digital flight control system 
for the Shuttle. The design ground rules for the TRCS specified a fail 
operational/ fail safe system in which a single failure would not degrade the 
operational performance and a second subsequent failure, detected or undetected, 
v/ould not create an unsafe flight condition. 

Hie usual method of achieving a triple redundant flight control system 
utilizes three of everything (i.e., three pitch rate gyros, three air data 
sensors, three accelerometers, three flight control computers, etc.) to form 
three independent commands for each control channel. The three independent 
commands are generally compared and passed by some form of selection logic 
within the servo actuator. The requirement for independent command generation 
precludes any cross strapping of sensor data between flight control computers. 
Consequently, when a failure occurs within one of the redundant paths, the 
entire path is lost and the flight control system reverts to a simple redun- 
dant system (two independent paths) . 

The objective of the TRCS contractual effort was to integrate three D216 
computers into a TRCS by accomplishing the following tasks : 

1) Develop the necessary software required to implement the TRCS. 

2) Design and fabricate an I/O processor (.TOP) to provide the data 
interface between the computers and the sensors/ servo actuators 
via a multiplex bus system produced by NASA. 
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2.2 TECS CONFIGURATION 

An overall block diagram of the TRCS is shown in Figure 2-1. The three 
flight control computers operate on data received from the sensor subsystems 
and generate commands for the control mechanisms , The flignt control sensors 
are all triple redundant with the exception of the single IMU. However, the 
IMU data is received over three independent and separate multiplex systems. 

The other 'sensors' include the rotation hand controller, attitude rate gyros 
(three axis), air data subsystem, and guidance commands from the guidance 
conputers . The present state of the TRCS does not include the guidance 
computers , and consequently position data (range to go and altitude) are 
input from the air data subsystem. The flight control computers each generate 

and transmit commands to the elevons, rudder, speed brake, and reaction 

S 

control system (RCS). Hie servo commands are force averaged in the elevon, 
rudder and speed brake actuators. This continues until one command becomes 
out of tolerance with respect to the other redundant commands. At that point 
the servo actuator to which these commands were transmitted disengages the 
faulty channel and continues operation with the remaining two redundant 
commands. Similar voting is performed for the RCS electronically. 

The TRCS description up to this point follows fairly closely the standard 
approach to designing a triple redundant control system. The TRCS differs by 
utilizing the digital computer capability to perform a redundant data manage- 
ment operation on all sensor data. In order to implement this data management 
function, it was necessary that (1) all three computers receive all three sets 
of sensor data, (2) the three computers be synchronized, and (3) a single 
computer failure would not affect the operation of the other two computers. 
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2.3 TRCS OPERATION 

Figure 2-2 shows a more detailed block diagram c£ the computer/ I OP inter- 
face with the sensors and actuators, and Figure 2-3 shows the organization of 
the I OP. The three flight control computers are synchronized v/ithin a few 
microseconds through a software mechanization every 40 msec. After synchro- 
nization, each computer issues a discrete request to its associated I OP for 
data input. According to a program stored in the IOP from the computer at 
power up, each IOP then proceeds to request data from its associated sensors. 
Tne data requests are transmitted to the Digital Interface Units (DIU) via 
the Bus Control Unit (BCU) and multiplex bus. Hie digital data returns along 
the same transmission path and is stored in the I/O buffer within the IOP. 

At the same time, the same data is transmitted to the exchange buffer (A) or 
(B) of the other IOP's. Consequently, when the data input is complete to the 
IOP, all three sets of sensor data are then input to the computer via direct 
memory addressing (DMA) under control of the IOP. A similar operation is 
actuated during output so that each computer has access to the flight control 
commands generated by the other computers in addition to its own. The output 
commands are compared within each computer for monitoring only. Any disengage 
ment of redundant commands is accomplished manually or by the servo actuator, 
not by. computer coimands . 

In addition to inputting flight control data to the conputers, the IOP 
acquires data for the Performance Monitoring System (PMS), The PMS data, 
including data from the computer, is stored in a buffer memory within the IOP 
for access by the PM system. In addition, a fifth buffer memory is provided 
for electronic display processing (EDP) . Hie EDP also provides for an exami- 
nation of the computer memory word by word. 
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As long as all three computers and IOP's are operating, each coirputer 
has all three redundant sets of sensor data. If one of the computers or one 
IOP fails, the set of sensor data associated with that computer/ IOP combination 
is lost to the other two computers; but both computers will continue with the 
remaining two sets of sensor data. 

Synchronization of the three computers is accomplished with a flexible 
real-time software method involving discrete inputs, discrete outputs and 
interrupts. A master- slave relationship is not used since it would not meet 
the requirement of independence. With this method control is shared among 
any operating computer combination. This permits the elapsed time between 
consecutive cycles to vary within controlled limits for correction of indi- 
victual computer clock variations. There is no compensation for accumulated 
time variations (with respect to real time) because it is not required by the 
system flight control mechanization. : 

A timing diagram of the IOP and computer operation over the 40 msec cycle 
time is shown in Figure 2-4. After the digital autopilot (DAP) data has been 
stored in the computer, a data selection/ redundant data management function 
is performed. 

2.4 DATA SELECTION 

The data selection/redundancy management function maintains a hard failure 
list and a soft failure list dependent on testing of the three sets of redun- 
dant data. The tests include a difference test, rate test and a magnitude 
test. If a single variable, such as pitch rate from one attitude rate gyro, 
fails these tests, that sensor is placed on the soft failure list. If it 
fails the tests during enough subsequent cycles, it is put on the hard fail 
list and is not used thereafter until manually reset. However, if subsequent 
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Figure 2-4, TRCS Timing Diagram 
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samples indicate good data, that sensor is removed from the soft failure list. 
The utilization of the three sets of sensor data is either mid -value, average 
of two good values, average of three good values, single good value or past 
value depending on the results of the tests. Each data variable is examined 
in conjunction with its redundant counterparts. For instance, if pitch rate 
is found to be bad, the rate gyro assembly , is not failed, just the pitch rate 
output. 

Since the software program is identical for each computer and each com- 
puter has access to identical data input, the autopilot commands should be 
identical. The DAP characteristics are shown in Table 2-1. 

Table 2-1. DAP CRAUCTERISTICS 

. Couple te Digital Autopilot 

. Milt i -Mode 

Manual - Direct, Pate Command, Rate Command Attitude Hold 
Automatic - 

. Phases - Booster TVC, Insertion TVC, Orbit RCS, Orbit TVC, 

Entry, Transition, Cruise, Roll Out 

. Filtering Technique - Difference Equation (2nd Order/2nd Order) 1 

. 25/second Iteration Rate 
3-Axis Attitude Control Plus Speed Brahe 
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3.0 DISPLAY AND KEYBOARD SUBSYSTEM 

3.1 GENERAL 

The Displays and Controls Subsystem (D§C) provides the information to 
pilot and manage both the mated vehicle and the orbiter vehicle and to handle 
payloads when in the payload bay and when in rendezvous. The D^C is organized 
into five, crew stations, two forward facing primary flight stations, one aft 
facing payload handling station, a subsystem and power distribution station 
and a mission specialist station used for management and checkout of active 
payloads with CCTV monitors and remote handling equipment. CRT displays are 
used to display graphic and alphanumeric data. Dedicated hardware is provided 
for caution and warning functions. 

} 

Table 3-1 lists the equipments comprising the Displays and Controls Sub- 
systems and their utilization by mission phase for a seven-day polar mission. 

The purpose of this section is to identify the Display and Keyboard Sub- 
system (D§K) which is a component part of the DSC subsystem and is comprised 
of CRT's, display electroni.cs and keyboards as indicated by the asterisks in 
Table 3-1. To be consistent with current Space Shuttle nomenclature, these 
equipments are hereafter referred to as Mai ti function CRT Display Subsystem 
(MCDS) . 

3.2 MULTIFUNCTION CRT DISPLAY SUBSYSTEM (MCDS) 

3.2.1 Introduction 

The fundamental purpose of the MCDS is to provide the means for the visual 
display of data to the individual crew stations. Hie MCDS is the bi-directional 
man/machine interface between the flight crew and the Data Processor Subsystem 
(DPS) or computers. The interface part of the DPS is the Input-Output Buffer 
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Rotation Hand Control 
Trans, Hand Controller 
Kanip. Hand Controller 
Manip, Hand Controller i/F 
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Master Thrust Controller 
Internal Lighting System 
Mission Timer 
Event Timer 

Gimbal Angle /Surf Position 
Ind. 

”G” Meter 
TAT Indicator 
Beta Meter 
Alpha Meter 
Stand By Compass 
Landing Gear Control 
Annuciator Light Matrix 
^Display Elect* 

^Keyboard 
*CRT Display Unit 
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Table 3-1. Avionics Equipment Utilization List by Mission Phase 

7 -Day Polar Mission 




(IOB) * The IQB interfaces with the M33S are via the Multiplexer Interface 
Assembly (MIA) in the IQB and the Display Electronics Unit (DEU) of the. MODS. 

The man-machine interface consists functionally of the display of DPS 
and/or sensor data for crew use, a method to manually enter the data into the 
DPS and a method to manually command DPS processed events. Thus, a display 
capability and. a keyboard capability are supplied. The keyboard capability 
is provided by a numeric keyboard with function keys added for the various 
control requirements. A block diagram of an integrated display xor a typical 
crew station is shown in Figure 3-1. 



Figure 3-1. Typical Crew Station Integrated Display 
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3.2.2 Primary Baseline Requirements 

The primary baseline requirements for the MCDS are summarized below. 
Alphanumerics - Test and Tabular 

16 x 32 + Title and Scratch Pad Lines 
Graphics - Simple Vectors 
Update - 2/sec 
Refresh - 50 to 60/sec 

Integral Refresh Buffer, Symbol Generation 

Integral Field - Programmable ROM Storage for Critical 
Format Skeletons 

3.2.3 Baseline Capabilities and Limitations 

The capabilities and limitations of the baseline MCDS are tabularized 
below. 

Can Do Cannot Do 

Quasi -Steady State Graphics Dynamic Flight Formats 

e.g., EADI, EHSI 

Graphics Involving Few Segments Moving Map Displays 

High Update Rates 

2 Sizes of Alpha Characters/Symbols Superimposed Raster 

Direct Conic Generation 

Blink (Intensity) Rotation or Translation of Symbol 

Groups Computation - Scaling, 
Vector Resolution, Etc. 

3.2.4 MCDS Description 
3. 2. 4.1 General 

The MCDS consists of the following units. 

4 - Identical Display Electronics Units (DEU's) 

4 - Identical CRT Display Units (CDU’s) 

. 3 - Identical Keyboard Units (KBU's) 
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The CDU’s and ICBU’s are time shared with functions dedicated to Guidance 
Navigation and Control (GN$C) , Payload Handling and Management (PLH/M) and 
Performance Monitoring Subsystem (PMS) . 

Provisions for the inclusion of a complete fifth display set have also 
been included for the purposes, of payload management. Reference Figure 3-2 
for the electrical interfaces between the M2DS and the DPS. The payload 
management display set is shown in broken lines. 

3.2. 4. 2 Display Electronics Unit (DEU) 

A. DEU Baseline Characteristic Summary . The baseline characteristics 
of the DEU are summarized below. 

. INTERFACES 

- Serial Manchester (I OB) 

- Digital (Keyboard) 

- Differential Analog (DU) 

- Composite Video (Option) 

. MENDRY 

- IK x 16 bit Monolithic R/W 

- 4K x 16 bit Monolithic PROM 

. SYMBOL GENERATION 

- A/N § 22 Special Symbols 

- Symbol Height 0.150" and 0.22", 0.75 Aspect 

- Vector Graphics 

- Tabular Format - 16 lines of 32 characters 

- Refresh 60 Hz 

- Symbol Gen. Time - Not defined 

- Settling Time - <40ys 

- Vector Speed - Not Defined 

- Positioning Matrix 1024 x 853 

B. Operational Description . The DEU receives data and commands from 
the DPS and from the KBU. These data and commands are processed to 
perform the required functions listed in Table 3-2. 
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Figure 5-2. Multifunction CRT Display Subsystem Interconnection 









Table 3-2. BECJ Functions 


1. Receives and decodes computer supplied display data. 

2. Stores display instructions in the refresh buffer and then 
executes them. 

3. Provides EDM storage of the stroking information for the (64) 
character symbol set. 

4. Provides storage for format skeletons for critical displays 
(in programmable ROM's). 

5„ Combines the static format (skeletons) and the dynamic data 
(changeable) in the display generation process, 

6. Fetches display skeletons from local storage. 

7. Receives s decodes and executes, when appropriate, display . 
requests from the' keyboard. 

<h Receives and displays computer input data entered via the 
keyboard* 

In order to accomplish the functions outlined in Table 3-2, a 
block diagram* Figure 3-3, showing all the elemental functions was 

prepared to assist in the explanation of the theory of operation of 

* 

the DEU. 

The DEU receives data from one of the conputers over one of- the 
MIX channels at a time. The computer transmits all the data/ instruc- 
tions necessary for a display. The display is broken up into two 
distinct parts: 

1. Static data - that part of the display that is constant 
and will only change when the display changes. 

2. Dynamic data - that part of the display that does or 
could change with time. 

The static data for the display is transmitted first and identified 
as such. Then the dynamic data for the display are transmitted. 

The dynamic data can be updated (i.e. , transmitted with changes) 
at a 2 Hz rate. The static and dynamic data are combined to complete 
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the display format before transmittal to the CRT display. 

The static data may also be fetched from PROM storage within 
the DEU. In this case, the DEU recognizes the format request code 
and displays the appropriate one. The DEU has the capability to 
store 4K x 16 bit words. Initially, this is RAM (loadable from an 
outside source) and is used to debug the skeletons . After the 
skeletons are developed, the method of storage will be PROM. 

i 

' The DEU to IOB interface is by means of two transformer coupled 

half duplexed serial, lines which constitute a full duplexed channel. 

The signal form is Manchester encoded 1 MHz self- clocking. A check 

method is included such that each message includes an 11- bit error 

Protection Code (EPC) which must be generated by the sender and 

- ? 

checked by the receiver. The interface levels are normal T"L vdth 
the transmission line being twin-ax or twisted, shielded pair with 
70 ohn characteristic impedance. The basic block diagram of the 
transmitter/receiver unit is shown in Figure 3-4. 

C. Functional Requirements /Packaging . The functional requirements 
listed below, if combined into similar implied hardware (i.e., 
storage control, etc.) would produce the block function packaging 
configuration represented in the DEU Block Diagram, Figure 3-5. 

1. Interface with IOB 

A. Receive and decode MIA messages 

B. Compose and transmit MIA messages 

C. Detect and generate error 

2. Interface with Keyboard Electronics 

A. Receive serial clocked keystroke data 

B. (Optional) Transmit clock to the keyboard 

C. (Optional) Supply power for keyboard electronics 
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3 . Storage 

A. RAM or register type storage for variable data, current 
image (i.e., refresh memory) and keyboard scratch pad 

B. ROM type for local storage of flight critical display 
skeletons 

4. Data Handling 

A. Decode command messages from IOB 

B. Compose images from specified fixed and variable data 

C . Update variable data in current image ; i.e,, refresh 
memory 

D. Interpret keyboard characters 

E. Perform keyboard action sequence 

F. Compose message words for IOB 

5 . Interface with CRTU (or CDU) 

A. Provide XY deflection and 2 intensity signals 

B. Accept CRTU-BITE outputs for reporting to the per- 
formance monitors system via an IOB 

C. Generate stroke data for deflection by means of data 
from refresh memory and character generator 

3. 2. 4. 3 Keyboard Unit (KBU) 

A, Operational Description . The KBU provides the capability for the ; 
manual selection of mission profile data and performance monitoring 

i 

data and provides for data entry update to the computer, as well as 
the data flow path to the MCDS. 

B. Functional Requirements . The keyboard shall have ten numeric keys, 
two algebraic sign keys, a decimal point key and a minimum of 15 
special function keys. The binary code assigned to each key is 
tabularized in Table 3-3, 

With the exception of the 'Display Designate" keys, all keys 
will be of the internally lighted momentary pushbutton type. The 
'Display Designate" keys will be of the push ON, push OFF type 
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Table 3-3. Binary Code Assignment to KBU Keys 


Code Key Possible Function 

00000 “ 0 ” 

00001 ” 1 ” 

00010 n 2" 

00011 ”3" 

00100 ,, 4 M 

00101 "5” 

00110 " 6 " 

00111 "7" 

01000 , 5 8 " 

01001 " 9 ” 

01010 

01011 

01100 

01101 Function #1 (Critical Formats) 
OHIO Function #2 (Other Formats) 
01111 Function #3 (Enter) 


Code Key, P ossible Function 
10000 Function #4 (Item) 


10001 

#5 (Execute) 

10 D10 

#6 (Space) 

10011 

#7 (Clear) 

10100 

#8 

10101 

#9. 

10110 

#10 (Operate) 

10111 

#11 (Stand By) 

11000 

#12 (Repeat) 

11001 

#13 (Acknowledge) 

11010 

#14 (Designate I) 

11011 

#15 (Designate II) 


button; and adequate interlocking will be provided to prevent desig- 
nation of two displays simultaneously. 

The KBU also includes the electronics to provide the necessary 
functions of roll over and anti-repeat interlocks, encoding, and 
serial transmission to the DRJ. The method of power supply and clock 
source has not yet been determined. (It is recommended that both 
.clock and power for the keyboard electronics be supplied from the 
DEU T s on -bus formatted distribution for redundancy.) 

3.2.5 MCDS Functional Capability 
3.2. 5.1 Quiescent State . 

In the absence of any request for action from the KBU or from the DPS 
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and no failure is present, the DEL 1 provides signals as required to the DU to 
keep the present display refreshed. The Keyboard Interface and the DPS 
receiver are in a ’’Listen” mode and the DEU is in a state to respond to DU 
and internal BITE signals. The DEU maintains this state and produces no 
activity except the refresh function. If a portion of the display is to blink 
by former setup, this is considered part of the Refresh function. 

3. 2. 5. 2 Communication 

Hie capability exists to transmit requests to the computers and to 
receive commands . from the computers. Each transmission consists of a control 
word followed by a specified number of data words. A format for the control 
and data words is shown in Figure 3-6. The 16 data bits contained in the 
data word format are used to define the type of display character or vector 
to be derived from a stroke generator. Preliminary formats for this use are 
shown in Figure 3-7. The first four bits are a control code which determines 
the significance of the remaining 12 bits. _ 

3 . 2 . 5 . 3 Keyboard Operations 

The capability exists in the DEU to accept character information from 
the KBU, to interpret the character and take appropriate action. See Figure 
3-8 for character assignments. The "appropriate actions” are not fully 
defined at this time except through inference. A capability exists to buffer 
KBU entries and display them on a scratch pad line so that the operator may 
visually check the entry. It is good practice to use this capability for as 
many of the keys as possible. It may be assumed, however, that at least one 
function will not, since something like "ENTER” is required to authorize 
action on the scratch pad data. 

3 . 2 . 5 . 4 Display Functions 

The DEU has the capability to generate, through stroke formats, a set of 
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COMMAND WORD 


DATA WORD 


Bits 

Function 

X“3 

Sync 

4-7 

MSG Control 

8-12 

Address 

13 

MIA Area 

14-22 

LRU Channel Address 

23-27 

No, of Words 

28-38 

Error Protection Code 


Bits 

Function 

i-3 

Sync 

4-11 

Control Field 

12-27 

Data 

28-38 

Error Protection Code 


Figure 3-6. DPS/MCDS Interface Word Formats 
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\Bit 

CommancNsNo . 
DATA MODE 

INITIAL POS. 
(GRAPHICS) 


CHARACTER 



5 6 7 $ 9 10 11 12 13 14 IS 16 


1111 

n 

n 

n 

n 


— r -A 

JL- . - 

LO 

i- 

I J—Start of Data 
End of 

. j Dynamic 

1 — — Static 


0 0 0 0 

9 Bits Data 

ZJ 

i. ■ 

1. if X = 0 




if Y - 1 


! “ — i 

o 

o 

V-* 

Cl 

C2 


TYPEWRITER MODE 
INITLAL POSITION 


THETA (GRAPHICS) 


LENGTH (GRAPHICS) 


FETCH DATA 

(from variable buffer 
area) 


CHARACTERS 

(GRAPHICS) 


o 

o 

o 

r— 1 
— - 

Y 

If matrix positions for tabulai 
alphanumeric s are used. 

0 0 0 1 


9 bits (in radians) ! 

■ — ■ — ' ■ - 


0 0 10 

□ 

' ^ 
9 bits data 

■ 

* 


L 0 if X is longer 
1 if Y is longer 


Size — Intensity 


— — . ' ■ — 

0 0 11 

Char Code 

, 

— 

i 1 

□ 

□ 

□ 


■■ ■ — — 

L— B1 ink 


□ 


0 10 0 


Address 


Character Count [ 



Figure 3-7. Basic Display Control Field Codes 
3-16 










































required alphanumeric, special character and simple vector displays as well 
as intensity control for at least blink, normal and brightened intensities. 

Hie DEU also has the capability to combine fixed and variable data to refresh 
the display and to handle responses from BITE. The CDU has automatic features 
such as phosphor protect and intensity adjust to ambient conditions. 
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4.0 TRCS/DISPLAY AND KEYBOARD SUBSYSTEM INTERFACE 

4.1 FUNCTIONAL INTERFACE 

• Table 4-1 outlines the functional requirements of the system. This dis- 
cussion covers the functional aspects of the interface of the TRCS to the 
Display and Keyboard Subsystem. 

A communications link exists between the TRCS Input -Output Box and the 
Display Electronics Unit. The DEU further communicates with the keyboards and 
the Display Unit. The computers, the IOB's and the communi cation channels are 
sufficiently redundant that they may be assumed operational for the following 
discussions. See Table 4-2 for message flow definitions. 

4.2 TRCS FUNCTIONS 

The TRCS system will receive messages from the DEU whenever the keyboard 
has requested a new display format. Hie TRCS shall supply a display skeleton 
from mass memory or a code word which identifies a skeleton stored in DEU 
memory. The TRCS will provide this transmission only once, then proceed with 
the following: a list of variable data is prepared in the TRCS and transmitted 

to the DEU. The list will include at least the system variables required for 
the present display. The lists may be grouped differently than the displays 
such that one list may be used for several displays if this is desirable. In 
any event the TRCS will establish the correct list from data in the original 
request from the DEU. The variables will be processed and provided in units 
required by the display and will be converted to binary or to BCD as estab- 
lished by the display requirements. 

4.3 DEU FUNCTIONS 

The DEU consists of interface circuitry, memory control logic and 
registers. Data are accepted from the keyboard which initiates a transfer 
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Table 4-1. Functional Requirements 


CREW STATIONS 

Four stations utilizing milt i function CRT's 

Two forward facing primary flight (3 CRT’s and 2 Kybd's) 

Subsystem Management (1 CRT and 1 Kybd) 

Mission Specialist Cl CRT and 1 Kyod when 

payload requires) 

FUNCTIONAL RELIABILITY 

Functions essential to crew/ vehicle safety FO/FS 

Functions nonessential to crew/vehic.le safety FS 

75 to 100 of the total of 400 formats are essential to 
crew/ vehicle safety 

FUNCTIONAL OPERATION 

Each keyboard can input to each computer 

Each CRT can display from each conputer , 

Each format can display on each CRT 

All stations can operate simultaneously (display and data 
entry) with the same format 

Essential foimat access time not more than 1 second 
Nonessential format access time not more than 5 seconds 
Keyboards have numeric and small number of special function keys 
Normal operation by two -man flight crew 
Safe return by single crewman from either seat 


2 per sec 
>55 per sec 


DATA RATES 

Variable Data 
Refresh 
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Table 4-2. ffessage Flow Definition 


TRCS to Display System Messages 

1. Data Lists 

2. Display Format Skeletons 

3. Data Requests 

4. Action Request or Alert to an Option Notice 

Display System to TRCS Messages 

1. Request for New Display Format 

2. Response to Computer Request 

Keyboard to Display Messages 

1. Numerical Data 

2. Special Function Data 

3. Configuration Control 




of a display request from memory to the TRCS coiremmi cation equipment. The 
TRCS then returns the skeleton (Display Program) which the DEU stores in its 
active memory’. If the TRCS returns a code which identifies a skeleton con- 
tained in DEU cold memory, then the data in that code are used to set up an 
indirect addressing mode which causes the program (skeleton) to be the next 
executed. When the data list starts arriving from the TRCS, it is stored in 
DEU memory in accordance with reference addresses in a "dictionary” section 
of the skeleton. 

Further functions of the DEU related to the man -machine interface must 
also be considered. In addition to number keys, there are several "Function" 
keys on the keyboard, which are related to the manner in which the operator 
and the machine are to function together. These indicate some functional 
operations which are considered next. 

Class A Actions - Operator requests a display to be called. 

Data Required - Identification of the particular format desired - 
This ID may be complete in the keyboard message or may be implicit 
from the present display and an abbreviation keyboard response; i.e., 

1 ’PROCEED," etc. 

Class B Actions - Operator responds to a computer request.- This condition 
may result from data in the data list from the computer; i.e., a display 
entry is brightened or blinks, or a special request may come from the 
computer for a message to be displayed on a special "ALERT" line of the 
display. This keyboard response may be numerical data or an action 
authentication. 

4.4 REDUNDANCY MANAGEMENT 

All of the functions so far have been normal operating requirements. It 
is now noted that these operations may be required from more than one crew 
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station and mast be transferable between displays and keyboards to meet the 
minimum functional capability required in the presence of failures and varying 
crew work load. Redundancy management is simplified in display systems as 
opposed to some other subsystems because the displays are open loop; i.e,, if 
a display fails, the operator does not look at/utilize it any more. The capa- 
bility is required, however, to assign a keyboard to another display. The 
display electronics and display units are one for one, so no active redundancy 
management is required there. The keyboards are constrained to be non-single 
point failure, but that does not preclude a keyboard failure for the two fault 
fail safe case, which is required. However, if a keyboard has failed, both 
displays to which the remaining keyboard is assigned are still working since 
only two failures are assumed, and the conditions for safe return from one 
crew position are met. Thus, it is not necessary for the keyboard to be 
assigned to the third display. 

Conflicts between normal use of displays such as "Handover" and no n- 
nominal use such as reassigned keyboard may be resolved by use of the central 
display. Since this display is visible to both crewmen and controlled by 
either keyboard, cooperative interface functions can be handled procedurally . 

Since DEU's are dedicated to DU’s and keyboards have two push- latch -on 
mutually exclusive assignment keys, the physical display to computer inter- 
face is relatively simple. Each DEU has a hard wired address which is used as 
required to place coded messages on a bus or to recognize messages on bus for 
the particular unit. 

4.5 DISPLAY/TRCS INTERFACE 

The discussion thus far has pointed out that the functional character- 
istics are generalized to such an extent that the interface mechanization can 
be relatively simple, and the functional complexity is handled by firmware in 


4-5 



a manner similar to computer programs. Inis is a good approach because the 
capabilities are included for other BEU functions. Messages to be transmitted 
are composed by the processor and stored in an identified memory location. 

The mode of the bus controller is then set by the processor and data is 
transmitted using processor interrupts when data is needed. For received 
messages the teiminal equipment reads all messages on the bus. When a full 
message word is received, the address code is compared with hard wired 
address. Agreement issues a processor interrupt. The detailed functions of 
the interface mechanization are then controlled by program lists. Thus, the 
capability is provided to efficiently provide functions of variables as well 
as fixed functions. 

The described manner of determining functional characteristics by means 
of firmware has some impact on the execution capability of the display processor 
This impact is minimal since only local instructions are required. The impact 
will be: more extensive interrupt capability and the firming up of a require- 
ment for indefinite nesting of interrupts, indirect addresses and subroutines. 
This is not considered serious if a stored register architecture is used with 
a sufficiently high speed memory. 
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